Pull system

Lean software development

LSD의 원칙 중 하나인 Deliver as fast as possible의 도구.

There are two ways to assure that workers make the most effective use of their time. You can either tell them what to do or set things up so they can figure it out for themselves.

In a fast-moving environment, only the second option works. People who routinely deal with fluid situations, such as emergency workers and military personnel, do not depend on a remote commander to tell them how to respond to the latest development. They figure out how to respond to events with the other people who are on the scene.

When things are happening quickly, there is not enough time for information to travel up the chain of command and then come back down as directives. Therefore, methods for local signaling and commitment must be developed to coordinate work. One of the keys ways to do this is to let cusomers’ needs pull the work rather than have a schedule push the work. —p71, Chapter 4, Lean software development (book)

Software development schedules:

No schedule can make effective fine-grained work assignments in a complex environment with even modest variability. Depending on a computerized schedule to make work assignments and telling developers what to do are not the best ways to handle complex or changing situations. A more effective approach is to use a pull system that creates appropriate signaling and commitment mechanisms, so that team members can figure out for themselves the most productive way to spend their time. —p74

Big, visible chart:

One of the features of a Pull system is visual control, or management by sight. If work is going to be self-directing, then everyone must be able to see what is going on, what needs to be done, what problems exist, what progress is being made. Work cannot be self-directing until simple visual controls that are appropriate to the domain are in place, updated, and used to direct work. …

Lists of problems, idea for improvements, candidates for Refactoring, business impact of the system to date, daily build status, glossaries of the ubiquitous language, database test beds, testing backlog - all are candidates for entry onto a big, visible chart. InformationRadiators make problems visible, telegraph progress, and are an enabling mechanism for self-directing work. —p76